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DETAILED ACTION 

1 . This Action is in response to Application Number 1 0/601 ,237 received on 
6/19/2003. 

2. Claims 1-62 are presented for examination. 

Interference 

3. The request for interference filed 6/19/2003 is acknowledged. However, 
examination of this application has not been completed as required by 37 CFR 

41 .102(a). Consideration of a potential interference is premature. See MPEP § 2303. 
Oath/Declaration 

4. The oath or declaration is defective. A new oath or declaration in compliance 
with 37 CFR 1 .67(a) identifying this application by application number and filing date is 
required. See MPEP §§ 602.01 and 602.02. 

5. The oath or declaration is defective because: The Declaration recites the title, 
"INTELLIGENT NETWORK INTERFACE DEVICE AND SYSTEM FOR ACCELERATED 
COMMUNICATION", which does not correspond to the title of the Specification filed in 
the application, which recites, "HIGH PERFORMANCE NETWORK INTERFACE". 

Specification 

6. The specification is objected to as failing to provide proper antecedent basis for 
the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01 (o). Correction 
of the following is required: Claims 13 and 53 recite a "computer readable storage 
medium". Applicant's specification does not provide the proper antecedent basis for this 
terminology. 
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Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

7. Claims 25, 42 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

8. Claim 25 recites, "The method of claim 24, further comprising: transferring said 
TCB from said host computer system to said communication device." However, it 
appears in claim 24 that the TCB is generated at the communication device. Therefore 
it is unclear how the TCB is transferred from the host computer system to the 
communication device if such is generated at the communication device. Clarification 
or correction is respectfully requested. 

9. Claim 42 recites the limitation "said memory area contents" in the last line of the 
claim. There is insufficient antecedent basis for this limitation in the claim. 

Claim Rejections - 35 USC § 101 
35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

10. Claims 13 and 53 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. 
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Claim(s) 13 and 53 recite a "computer readable storage medium" which appears 
to cover both transitory and non-transitory embodiments. The United States Patent and 
Trademark Office (USPTO) is required to give claims their broadest reasonable 
interpretation consistent with the specification during proceedings before the USPTO. 
See In re Zletz, 893 F.2d 319 (Fed. Cir. 1989) (during patent examination the pending 
claims must be interpreted as broadly as their terms reasonably allow). The broadest 
reasonable interpretation of a claim drawn to a medium as claimed typically covers 
forms of non-transitory tangible media and transitory propagating signals perse in view 
of the ordinary and customary meaning of the term, particularly when the specification is 
silent of an explicit definition . See MPEP 21 1 1 .01 . When the broadest reasonable 
interpretation of a claim covers a signal perse, the claim must be rejected under 
35 U.S.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 
1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory 
subject matter) and Interim Examination Instructions for Evaluating Subject Matter 
Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. 

The Examiner suggests that the Applicant add the limitation "non-transitory" to 
the medium as recited in the claim(s) in order to properly render the claim(s) in statutory 
form in view of their broadest reasonable interpretation in light of the originally filed 
specification. The Examiner also suggests that the specification may be amended to 
include the medium to be described as non-transitory in order to avoid a potential 
objection to the specification for a lack of antecedent basis of the claimed terminology. 
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11. As such, claims 1 3 and 53 are not limited to statutory subject matter and are 
therefore non-statutory. 



Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

12. Claims 1-12, 14-17, 20-31, 42-44, 46-53, 55-56 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Flanders et al. (US 6172980). 

13. Regarding claims 1 , 24, 53, Flanders disclosed a method of transferring a packet 
to a computer system, wherein the packet is received at a communication device from a 
network (Flanders, col. 1 , lines 39-41 , a network router receiving and routing packets), 
comprising: 

parsing a header portion of a first packet received at a communication device to 
determine if said first packet conforms to a pre-selected protocol (Flanders, col. 3, lines 
60-65, "RHP (Receive Header Processor) determines the protocol being used for the 
received data unit"; See also col. 6, lines 50-51); 
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generating a flow key to identify a first communication flow that includes said first 
packet (Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from 
the received frame in order to classify packet according to flow ID, the information 
extracted from the packet used as a flow key to look the packet up); 

routing the packets to their destination (Flanders, col. 1, lines 50-55, Flanders 
disclosed the router making forwarding decisions to route the packet, see also Abstract, 
"identifying a data unit to be routed by a router) 

associating an operation code with said first packet, wherein said operation code 
indicates a status of said first packet (Flanders, col. 6, line 65 through col. 7, line 15, in 
accordance with the received frame, a status word is set; see also, col. 4, lines 15-23). 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the disclosed 
device system for processing in accordance with said pre-selected protocol. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 
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Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

Claim 24 includes a method with limitations that are substantially similar to the 
limitations of claim 1 , and is therefore rejected under the same rationale. Claim 53 
recites a computer readable storage medium storing instructions that perform the 
method of claim 1 . Therefore claims 24, 53 are rejected under the same rationale. 

14. Regarding claim 2, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing comprises: copying a header portion of said first packet 
into a header memory; and examining said header portion according to a series of 
parsing instructions; wherein said parsing instructions are configured to reflect a set of 
pre-selected communication protocols (col. 3, lines 45-65). 

15. Regarding claim 3, Flanders disclosed the limitations as described in claim 2. 
Flanders did not explicitly wherein said parsing instructions are updateable. However, it 
would have been obvious to any programmer or designer at the time the invention was 
made that any instructions carried out by a machine are updateable, as any software or 
hardware could be updated in order to accommodate the desires of the 
programmer/designer. 
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16. Regarding claim 4, Flanders disclosed the limitations as described in claim 2, 
including copying a value from a field in a header of said header portion (Flanders, col. 
6, lines 50-56). 

17. Regarding claim 5, Flanders disclosed the limitations as described in claim 1, 
including wherein said parsing comprises: extracting an identifier of a source of said first 
packet from said header portion; and extracting an identifier of a destination of said first 
packet from said header portion (Flanders, col. 3, lines 55-60). 

18. Regarding claim 6, Flanders disclosed the limitations as described in claim 5, 
including combining said source identifier and said destination identifier (Flanders, col. 
3, lines 55-60). 

19. Regarding claim 7, Flanders disclosed the limitations as described in claim 1, 
including 

wherein said generating comprises retrieving an identifier of a communication 
connection from said header portion (Flanders, col. 6, lines 49-60). 

20. Regarding claim 8, Flanders disclosed the limitations as described in claim 1 , 
including storing said first packet in a packet memory prior to said transferring 
(Flanders, col. 3, lines 45-55). 
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21 . Regarding claim 9, Flanders disclosed the limitations as described in claim 1 , 
including storing said flow key in a flow database, wherein said flow database is 
configured to facilitate management of said first communication flow (Flanders, col. 6, 
lines 50-65, "Flow Filtering Table"). 

22. Regarding claim 10, Flanders disclosed the limitations as described in claim 9, 
including associating a flow number with said first packet, wherein said flow number 
comprises an index of said flow key within said flow database (Flanders, col. 6, lines 50- 
65, "Flow ID"). 

23. Regarding claim 1 1 , Flanders disclosed the limitations as described in claim 1 0, 
including storing said flow number in a flow memory (Flanders, col. 6, lines 50-65, "Flow 
ID" is stored in the table). 

24. Regarding claim 12, Flanders disclosed the limitations as described in claim 9, 
including updating an entry in said flow database associated with said flow key when a 
second packet in said first communication flow is received (Flanders, col. 6, line 65 
through col. 7, line 15). 

25. Regarding claim 14, Flanders disclosed the limitations as described in claim 1, 
including wherein said associating comprises: retrieving one or more header fields of 
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said header portion; and analyzing said header fields to determine said status of said 
first packet (Flanders, col. 7, lines 1-15). 

26. Regarding claim 15, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises: determining whether said first packet 
includes a data portion; and if said first packet includes a data portion, determining 
whether said data portion exceeds a pre-determined size (Flanders, col. 4, lines 30-40). 

27. Regarding claim 16, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises determining whether said first packet was 
received out of order in said first communication flow (Flanders, Fig. 6, TCP which is 
enabled for out of order packets). 

28. Regarding claim 17, Flanders disclosed the limitations as described in claim 1, 
including storing said operation code in a control memory (Flanders, col. 7, lines 1-15). 

29. Regarding claim 20, Flanders disclosed the limitations as described in claim 1 , 
including determining whether a second packet received from said network is part of 
said first communication flow (col. 6, lines 50-65). 
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30. Regarding claim 21, Flanders disclosed the limitations as described in claim 20, 
including maintaining a packet memory configured to store one or more packets 
received from said network (col. 3, lines 45-55); 

maintaining a flow memory configured to store, for each of said one or more packets, an 
identifier of a communication flow comprising said packet (col. 6, lines 50-65); and 
searching said flow memory for a first identifier of said first communication flow (col. 6, 
lines 50-65). 

31 . Regarding claim 22, Flanders disclosed the limitations as described in claim 21 , 
including wherein said first identifier comprises said flow key (col. 6, lines 50-65). 

32. Regarding claim 23, Flanders disclosed the limitations as described in claim 21, 
including wherein said first identifier comprises a flow number of said first packet, 
wherein said flow number is an index of said flow key within a flow database (col. 6, 
lines 50-65). 

33. Regarding claim 25, Flanders disclosed the limitations as described in claim 24, 
including transferring said TCB from said host computer system to said communication 
device (col. 6, lines 50-65). 

34. Regarding claim 26, Flanders disclosed the limitations as described in claim 24, 
including receiving a second packet from a second communication flow; and processing 
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said second packet by said communication device in accordance with said TCB (col. 6, 
lines 50-60, all packets received go through the same process if they are part of the 
same flow). 

35. Regarding claim 27, Flanders disclosed the limitations as described in claim 1 , 
including alerting said host computer system to the arrival of said first packet (col. 9, 
lines 40-45). 

36. Regarding claim 28, Flanders disclosed the limitations as described in claim 1 , 
including maintaining a packet memory configured to store packets received from said 
network (col. 3, lines 47-55). Flanders did not explicitly state randomly discarding a 
packet if said packet memory contains a pre-determined level of traffic. However, it 
would have been obvious to one of ordinary skill in the art at the time the invention was 
made that buffered packets would be discarded as new packets arrive at the buffer, 
especially during the case that the buffer is completely filled, i.e. the packet memory 
contains a predetermined traffic level, in order to make room for new arriving packets 
and to allow the router to continue to operate properly. 

37. Regarding claim 29, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing includes determining, by hardware of the communication 
device, a protocol of the header (col. 3, lines 50-60). Flanders also clearly disclosed the 
teaching of multiple protocol support. 
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The teachings of Flanders does not limit itself to any particular type of protocol. 
This would have motivated one of ordinary skill in the art to implement the teachings of 
Flanders with any protocol well known in the art. 

The session layer is a well known layer from the OSI model. Therefore it would 
have been obvious to one of ordinary skill in the art at the time the invention was made 
to incorporate the session protocol within the teachings of Flanders since in order to 
make the teaching of Flanders scalable across well known protocols, thereby increasing 
its customer's desirability of use. 

38. Regarding claim 30, Flanders disclosed the limitations as described in claim 1 , 
including wherein said generating a flow key includes initializing a communication 
control block (CCB) during Transport Control Protocol (TCP) connection setup (col. 7, 
lines 10-15). 

39. Regarding claim 31 , Flanders disclosed the limitations as described in claim 1 , 
including wherein said communication device is a network interface (Fig. 1). 

40. Regarding claims 42 and 44, Claim 42 includes an apparatus with a memory and 
modules to perform the limitations that are substantially similar to claim 1 and claim 44 
recites a computer system with limitations that are substantially to claims 1 . Claims 42 
and 44 further includes a "flow re-assembler configured to re-assemble a data portion of 
said first packet with a data portion of second packet in said communication flow and 
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storing both packets in memory as well as a processor to process said packet. As 
shown in the rejection of claim 1, Flanders disclosed a router performing these 
limitations. 

Flanders did not explicitly state flow re-assembler configured to re-assemble a 
data portion of said first packet with a data portion of second packet in said 
communication flow and storing both packets in memory of the downstream network 
device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 



Application/Control Number: 1 0/601 ,237 Page 1 5 

Art Unit: 2443 

that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 

41 . Regarding claim 43, Flanders disclosed the limitations as described in claim 42, 
including wherein said traffic classifier comprises: a parser configured to parse a header 
portion of said first packet; a flow database configured to store a flow key identifying 
said communication flow; and a flow database manager configured to manage said flow 
database; wherein said flow key is generated from an identifier of a source of said first 
packet and an identifier of a destination of said first packet (Flanders, Flanders, col. 6, 
line 50 through col. 7, line 5, port information extracted from the received frame in order 
to classify packet according to flow ID, the information extracted from the packet used 
as a flow key to look the packet up, see also col. 1 , lines 50-61 ). 

42. Regarding claim 46, Flanders disclosed the limitations as described in claim 1 , 
wherein said operation code indicates whether the packet corresponds to Transport 
Control Protocol (TCP) (Flanders, col. 7, lines 10-15). 

43. Regarding claim 47, Flanders disclosed a device for receiving a packet from a 
network and transferring the packet to a host computer system, comprising: 
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a parser configured to parse a header portion of a packet received from a 
network, wherein said parsing comprises: determining whether a header within said 
header portion conforms to one of a set of communication protocols (Flanders, col. 3, 
lines 60-65, "RHP (Receive Header Processor) determines the protocol being used for 
the received data unit"; See also col. 6, lines 50-51); and 

if said header conforms to one of said communication protocols, extracting information 
from said header portion to identify a communication flow to which said packet belongs 
(Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from the 
received frame in order to classify packet according to flow ID, the information extracted 
from the packet used as a flow key to look the packet up); a flow memory configured to 
store a flow identifier for identifying said communication flow; a flow manager configured 
to assign an operation code to said packet, wherein said operation code: indicates a 
status of said packet; and indicates a manner of transferring said packet to the host 
computer system; a packet memory configured to store said packet (Flanders, col. 6, 
line 65 through col. 7, line 15, in accordance with the received frame, a status word is 
set; see also, col. 4, lines 15-23. Flanders further disclosed forwarding the packets for 
receipt by a downstream network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the disclosed 
device system for processing in accordance with said pre-selected protocol. 
However, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
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the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

44. Regarding claim 48, Flanders disclosed the limitations as described in claim 47, 
wherein the device is a network interface (Flanders, Abstract). 

45. Regarding claim 49, Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow database configured to store a flow key, wherein 
said flow key is assembled from an identifier of a source of said packet and an identifier 
of a destination of said packet (Flanders, col. 6, line 50 through col. 7, line 5, port 
information extracted from the received frame in order to classify packet according to 
flow ID, the information extracted from the packet used as a flow key to look the packet 
up; col. 1, lines 50-67). 
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46. Regarding claim 50, Flanders disclosed the limitations as described in claim 47, 
wherein said flow manager is further configured to update said flow memory as 
additional packets in said communication flow are received from the network (Flanders, 
col. 6, lines 50-67, col. 7, lines 1-5). 

47. Regarding claim 51 , Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow memory configured to store a flow number, wherein 
said flow number comprises an index of said communication flow in a flow database 
(Flanders, col. 6, lines 50-67, col. 7, lines 1-5). 

48. Regarding claim 52, Flanders disclosed the limitations as described in claim 47, 
further comprising a control memory configured to store said operation code (Flanders, 
col. 7, lines 1-5). 

49. Regarding claim 55, Flanders disclosed the limitations as described in claim 47, 
wherein said transfer module is configured to transfer a data portion of said packet into 
one of a set of host memory areas in accordance with said operation code (Flanders, 
col. 7, lines 1-15). 

50. Regarding claim 56, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state further comprising a packet batching module configured 
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to determine whether said packet memory contains another packet in said 
communication flow. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 
that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 
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51 . Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over Flanders 
et al. (US 6172980) in view of Lincoln (US 5991265). 

52. Regarding claim 18, Flanders disclosed the limitations as described in claim 1, 
including processing of the header at a Receive Header Processor (Flanders, col. 1, 
lines 50-60). 

Flanders did not explicitly state storing the data portion in a re-assembly storage 
area and one or more headers in a header storage area. 

In an analogous art of packet processing, Lincoln disclosed packet processing in 
which the system transfers the cell payloads to a reassembly memory while processing 
the headers from control memory and then combining the header and payload before 
transferring the cell (Lincoln, col. 5, lines 30-40). As such, Lincoln provides evidence 
that it is well known to divide packets between header and payload in order to perform 
header processing of the packets. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the splitting of packet header and payload as 
performed in the teachings of Lincoln in order to provide the system of Flanders in order 
to reduce the amount of data to be analyzed by the RHP in order to process the 
headers in a more efficient manner. 
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53. Claims 32, 45, 54 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Flanders et al. (US 6172980) in view of Seno et al. (US 5590328). 

54. Regarding claim 32, Flanders disclosed a method of transferring a packet 
received at a network interface to a host computer system, comprising: 

receiving a packet from a network, storing said packet in a packet memory and 
parsing a header portion of said packet; extracting a value stored in said header 
portion; identifying a communication flow comprising said packet (Flanders, col. 3, lines 
60-65, "RHP (Receive Header Processor) determines the protocol being used for the 
received data unit"; See also col. 6, lines 50-51 ; col. 6, line 50 through col. 7, line 5, port 
information extracted from the received frame in order to classify packet according to 
flow ID, the information extracted from the packet used as a flow key to look the packet 
up); 

determining whether a header in said header portion conforms to a pre-selected 
protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header Processor) determines 
the protocol being used for the received data unit"); 

determining whether a second packet in said packet memory is part of said 
communication flow (Flanders, col. 1, lines 39-40, Flanders disclosed performing the 
same for multiple received data units); and 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43) 
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Flanders did not explicitly state the step of storing said packet in a host memory 
area in the downstream network device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet, thereby 
requiring storing of the packet. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination actually storing the packet in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret that packet at the receiving end, thereby resulting in 
successful communication. 

Flanders also did not explicitly state wherein, if the host computer system 
contains a plurality of processors, identifying a processor to process said packet; 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet (Seno, col. 2, lines 35-65). 
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One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 

55. Regarding claim 45, Flanders disclosed the limitations as described in claim 42. 

Flanders also did not explicitly state wherein, comprising: a load distributor for 
identifying a first processor within the host computer system for processing said first 
packet and said second packet; wherein said load distributor identifies a second 
processor in the host computer system for processing a packet from a different 
communication flow. 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according to the communication (Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 
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Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 

56. Regarding claim 54, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state wherein said host computer system is a multi-processor 
host computer system, further comprising a load distributor configured to select one of 
said multiple processors for processing said packet in accordance with one of said 
communication protocols. 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according a protocol (Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
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improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 



Double Patenting 

57. Claims 1 , 24 are provisionally rejected on the ground of nonstatutory 
obviousness-type double patenting as being unpatentable over claim 31 of copending 
Application No. 10/634,062. Although the conflicting claims are not identical, they are 
not patentably distinct from each other because claim 31 of patent application 
10/634,062 contain(s) every element of claim 1 of the instant application and as such 
anticipate(s) claims 1 , 24 of the instant application. "A later patent claim is not 
patentably distinct from an earlier patent claim if the later claim is obvious over, or 
anticipated by, the earlier claim. In re Lonqi , 759 F.2d at 896, 225 USPQ at 651 
(affirming a holding of obviousness-type double patenting because the claims at issue 
were obvious over claims in four prior art patents); In re Berg , 140 F.3d at 1437, 46 
USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double 
patenting where a patent application claim to a genus is anticipated by a patent claim to 
a species within that genus). " ELI LILLY AND COMPANY v BARR LABORATORIES, 
INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR 
REHEARING EN BANC (DECIDED: May 30, 2001 ). This is a provisional obviousness- 
type double patenting rejection because the conflicting claims have not in fact been 
patented. 
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Allowable Subject Matter 

58. Claims 33-40, 58-62 allowed. 

59. Claims 1 9, 41 , 57 are objected to as being dependent upon a rejected base 
claim, but would be allowable if rewritten in independent form including all of the 
limitations of the base claim and any intervening claims. 

Conclusion 

Examiner's Note: Examiner has cited particular columns and line numbers in 
the references applied to the claims above for the convenience of the applicant. 
Although the specified citations are representative of the teachings of the art and are 
applied to specific limitations within the individual claim, other passages and figures 
may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety as potentially teaching all or part 
of the claimed invention, as well as the context of the passage as taught by the prior art 
or disclosed by the Examiner. 

In the case of amending the claimed invention, Applicant is respectfully 
requested to indicate the portion(s) of the specification which dictate(s) the structure 
relied on for proper interpretation and also to verify and ascertain the metes and bounds 
of the claimed invention. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Bret Dennison whose telephone number is (571) 272- 
3910. The examiner can normally be reached on M-F 8:30am-5pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tonia Dollinger can be reached on (571) 272-4170. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

/J Bret Dennison/ 

Primary Examiner, Art Unit 2443 



